Computerized devices control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized device. The cost of not discovering a bug may be enormous, as the consequences of the bug may be disastrous. For example, a bug may cause the injury of a person relying on the designated behavior of the computerized device. Additionally, a bug in hardware or firmware may be expensive to fix, as patching it requires call-back of the computerized device. Hence, many developers of computerized devices invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized device.
Functional verification of complex processor designs or other component designs is based largely on simulation-based techniques. These techniques generate stimuli in the form of machine-language programs. Faulty behavior of the design is detected by driving the stimuli into a simulator, such as a design simulator, and comparing the actual behavior of the design with the expected behavior implied by the input stimuli.
Architectural tests generators generate test cases for designs. The generator may receive as input a test template, which describes the architectural scenario required by the user, and generates tests that comply with the user scenario. The test template may define the scenarios either partly or fully. In case of partially specified scenarios the test generator randomizes the unspecified aspects of the scenario and biases them toward interesting architectural or micro architectural events.
A test in which the generated instructions access the same resource may be considered as having higher quality, as such test may operate some inter-instruction behavior, such as for example a cache mechanism. Tests may be considered of high quality in case instructions of the same functional unit are operated consecutively and/or concurrently. Tests may be considered of high quality based on additional parameters which are known to a person of ordinary skill in the art.
The scenario may be composed of a sequence of requests on the generated instructions. This may include various parameters such as (1) specifying requests that instructions would be of certain opcodes or types; (2) specifying requests that instructions would have certain operand values; (3) specifying requests that instructions would access (read/write/access) some resources (e.g. request for instructions that read from a specific register); (4) specifying requests that instructions would have some resulting behavior (e.g. take an exception); or the like. When the verification plan is focused on the micro architecture, the scenario may require instructions that have some micro architectural behavior, for example utilize a particular unit, or instructions with long execution time.
Architectural test generators utilize architectural knowledge and micro architectural knowledge of the Design Under Test (DUT), generally referred to in the present disclosure as design knowledge, in order to generate the tests in accordance with the defined scenario. Additionally or alternatively, the design knowledge is utilized to bias the scenario to interesting architectural or micro architectural events. For example, generation may be biased towards providing desired outcomes or side-effects, such as for example, accessing predetermined resource (e.g., register, memory space, and processor unit) or the like.
The term “design knowledge” in the present disclosure may refer to any information that is considered as either “micro architectural knowledge” and/or “architectural knowledge”, or similar information.
The architectural knowledge may include, for example, the instruction format and semantics, the registers, exception behavior, translation mechanisms and the like. The micro architectural knowledge may include, for example, a model of the execution time for each instruction, or the conditions for pipeline flushes. While the type of knowledge required is recurring and based on common micro architectural concepts (such as pipelines delays, instruction cracking, and instruction grouping), the details required to implement these requests are highly design specific and can change frequently during the project.